Recommended by the DAT Team
Some aims and assumptions that guide our recommendations…
Well… “travel light” perhaps!
Planning and design activities as well as code development aim to align to a regular release cadence.
The cadence of the next planned release is defined by the application team.
Planning assumptions should aim as much as possible to complete changes quickly, ideally within one release cycle.
Every change starts in a branch.
Developers work in the branch to make changes, perform user builds and unit tests.
A branch holds multiple commits (changes to multiple files).
Every change starts in a branch.
These changes on these branches are
main.mainFeature Team/Developers will:
mainCreate a Pull Request (PR) to signal to Team Leaders/Release Controllers to:
mainmain and other long-lived branches are protected (not everyone can push or merge to them).
CI/CD decouples the building and deploying to test environments and production.
We have no branches named prod (or test or QA)
Any point in the history of main can be declared a release candidate.
Tag the commit (point in main’s history) with a release name.
When all the committed work items for the next planned release are ready to be shipped, and all quality gates have passed successfully and the required approvals have been issued by the appropriate reviewers, the release package and be deployed to production.
Tag the commit (point in main’s history) with a release name.
A release maintenance branch will be used if hot-fixes must be developed and delivered.
Concurrent feature branches scale very well, but assume short cycle times.
Epic branches can collect multiple features
main(Epic branches are a form of integration branch.)
The principles are more important that the tools and names.
Naming conventions - making purpose obvious:
main : single source of truth. The only long-living branch.release/rel-2.0.1 : explicit versioning numbering to identify releases maintenance branch.epic/47-ai-fraud-detection : development initiative identified by epic id and description.Changes are implemented on feature branches:
feature/<jira-id|servicenow-id>-new-mortgage-calculation : references to other planning tools for new features for the next planned release.feature/47-ai-fraud-detection/refactor-mortgage-calculation: feature implemented for development initiativehotfix/rel-2.0.1/fix-mortgage-calc: fix implemented for release rel-2.0.1Names of branches and tags flow through to builds and deployments.
How do teams work with and benefit from the branch strategy?
Work and focus on the next planned release via the main branch. After planning the work items for the next release, the development team is adding changes to the main branch.
Resolution of a production problem in the currently-released version of the application by leveraging a release maintenance branch that is used for maintenance purposes,
concurrent development activities for significant development initiatives, which include multiple planned work items for a later delivery (including starting development of a future release) by creating an epic branch from a commit point in the history of main.
The following narratives complement the structure.
Developer activities:
Release control activities:
main and buildPipeline templates for the various pipeline orchestrators that implement the recommended workflow.
zDevOps adoption enablement website - Git branching for mainframe development
Recent blog post - A no-baggage approach to new Mainframe development practices
Pipeline templates - IBM DBB Community Repository
The process of urgent fixes for modules in the production environment follows the fix-forward approach, rather than rolling back the affected modules and reverting to the previous deployed state.
The development team starts this process by creating a release maintenance branch of the git tag that represents the most recent release, that was deployed to production.
Developer activities resolving a production defect:
release/rel-2.1.0 branch based on the existing Git taghotfix/rel-2.1.0/urgent-fix from the release maintenance branch.Release control activities resolving a production defect:
main.Dealing with significant development initiatives such as:
→ A process to work independently from the base workflow.
Developer activities for implementing significant development initiatives:
epic/ai-fraud-detection branch based on the existing Git tagfeature/ai-fraud-detection/introduce-ai-model-to-mortgage-calculation from the epic branch.Release activities for implementing significant development initiatives:
main into the epic branch to avoid making the merge of the epic branch into main difficult.main and deliver via the base workflow.Git tags are used to calculate the changes for the next planned release, release maintenance packages and larger development activities.
Packages are cumulative which is making it easier to get a test environment to the desired state (avoiding coordination of several incremental packages)
Copyright © 2024 IBM Corporation